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REMARKS 

In response to the Office Action dated February 28, 2006, the Assignee respectfully 
requests reconsideration based on the following remarks. The Assignee respectfully submits that 
the pending claims already distinguish over the cited documents to Sitaraman and to Allen. 

Claims 1-30 are pending in this application. 

Claims 5, 6, 16, 17, 27, and 28 were rejected under 35 U.S.C. § 112, first paragraph, for 
failing to comply with the enablement requirement. Claims 1-7, 10-18, and 21-30 were rejected 
under 35 U.S.C. § 102 (e) as being anticipated by U.S. Patent 6,718,332 to Sitaraman et al. 
Claims 9 and 20 were rejected under 35 U.S.C. § 103 (a) as being unpatentable over Sitaraman. 
Claims 8 and 19 were rejected under 35 U.S.C. § 103 (a) as being unpatentable over Sitaraman 
in view of U.S. Patent 6,078,918 to Allen et al. 

The Assignee shows, however, that the amended claims are neither obviated nor 
anticipated by the cited documents. The Assignee thus respectively submits that the pending 
claims already distinguish over the cited documents. 

Telephone Interview with Examiner Abrishamkar 

Examiner Abrishamkar discussed this response. A telephone interview was held 
Monday, May 8* between Examiner Abrishamkar and Scott Zimmerman. Attorney Scott 
Zimmerman explained that Sitaraman fails to disclose the claimed features "validation rules 
comprising at least three hierarchically organized views, with each view utilizing an execution 
sequence of validation methods" (emphasis added). Examiner Abrishamkar agreed and suggest 
this response be formally submitted. 

Rejection of Claims under 35 U.S.C. § 112 
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Claims 5, 6, 16, 17, 27, and 28 were rejected under 35 U.S.C. § 112, first paragraph, for 
failing to comply with the enablement requirement. 'The test of enablement is whether one 
reasonably skilled in the art could make or use the invention from the [disclosure] coupled with 
information known in the art without undue experimentation." Department of Commerce, 
Manual of Patent Examining Procedure § 2164.01 (Rev. 1, Feb. 2003) (hereinafter "M.P.E.P.") 
(quoting United States v. Telectronics, Inc., 8 U.S.P.Q.2d 1217, 1233 (Fed. Cir. 1998). The 
Examiner has the initial burden, and "the minimal requirement is for the Examiner to give 
reasons for the uncertainty of the enablement." M.P.E.P. § 2164.04. "A specification ... which 
contains a teaching of the manner and process of making and using an invention in terms which 
correspond in scope to those used in describing and defining the subject matter sought to be 
patented must be taken as being in compliance with the enablement requirement." M.P.E.P. § 
2164.04. 

1 . Claims 5, 16 & 27 are Enabled 

Claims 5, 16, and 27 are enabled. Examiner Abrishamkar's sole reasoning for lack of 
enablement is that "there is no mention of converting legacy data to string values in the 
specification, and therefore, it is believed that this limitation is not enabled." Examiner 
Abrishamkar, February 28, 2006 Office Action, at page 3. Support for claims 5, 16, and 27, 
however, may be found at least in paragraphs [0037] and [0038] of the as-filed application, 
which are reproduced below: 

[0037] The most generic field type in Java is the string. In the preferred embodiment, all data 
passed to the validation server 100 will be treated as a string. This will allow applications 400 
to change to more generic data without impact. This embodiment will provide an interface that is 
as generic as possible by establishing the interface as Strings (ASCII). An example of this concept 
is set forth below. 

[0038] As an example, assume that a business requirement was originally for an integer value for 
the Class of Service variable. However, since the integer values can be type cast to String and 
passed to the validation server 100, modifications to the rules can be made quickly. Modifications 
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to types would cause the validation server 100 to understand application knowledge and not data 

values and validation rules. Testing with the legacy system determines that the value of 

NnmberOfTelephoneLines may also be a single alpha character in some legacy systems. 

According to the present invention, since the variable is stored as a string the client code is not 

affected. Accordingly, the validation functions in the data table can be changed to an 

IsMember method instead of an IsBetween method. The validation value data will include all 

possible valid data values. This will change the validation from a check between two integer 

values (e.g., a number between 1 and 5) to a check for a member of the a set (e.g., 

1,2,3,4, 5,A,T,Y). This could be done without disturbing the running applications that utilize this 

validation service. 

U.S. Application 09/995,648 at paragraphs [0037] and [0038] (emphasis added). 

Claims 5, 16, and 27, then, are fully enabled. Because the as-filed specification contains 
a teaching in terms which correspond in scope to those used in claims 5, 16, and 27, these claims 
must be taken as being in compliance with the enablement requirement. Accordingly, the 
Assignee respectfuDy requests removal of the § 112 rejection of claims 5, 16, and 27'. 

1. Claims 6, 17 & 28 are Enabled 

Claims 6, 17, and 28 are, likewise, enabled. Again. Examiner Abrishamkar's sole 
reasoning for lack of enablement is that "there is no mention of changing the legacy data to check 
for membership in a data set, and therefore, the limitation is believed to be not enabled." 
Examiner Abrishamkar, February 28, 2006 Office Action, at page 3. Support for claims 6, 17, 
and 28, however, may be found at least in paragraph [0038] of the as-filed application, which are 
reproduced below: 

[0038] As an example, assume that a business requirement was originally for an integer value for 
the Class of Service variable. However, since the integer values can be type cast to String and 
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passed to the validation server 100, modifications to the rules can be made quickly. Modifications 

to types would cause the validation server 100 to understand application knowledge and not data 

values and validation rules. Testing with the legacy system determines that the value of 

NumberOfTelephoneLuies may also be a single alpha character in some legacy systems. 

According to the present invention, since the variable is stored as a string the client code is not 

affected. Accordingly, the validation functions in the data table can be changed to an 

IsMember method instead of an IsBetween method. The validation value data will include all 

possible valid data values. This will change the validation from a check between two integer 

values (e.g., a number between 1 and 5) to a check for a member of the a set (e.g., 

1,2,3,4,5 A,T,Y). This could be done without disturbing the running applications that utilize this 

validation service. 

U.S. Application 09/995,648 at paragraph [0038] (emphasis added). 

Claims 6, 17, and 28, then, are fully enabled. Because the as-filed specification contains 
a teaching in terms which correspond in scope to those used in claims 6, 17, and 28, these claims 
must be taken as being in compliance with the enablement requirement. Accordingly, the 
Assignee respectfully requests removal of the § 112 rejection of claims 6, 17, and 28. 

Rejection of Claims under 35 U.S.C. § 102 

Claims 1-7, 10-18, and 21-30 were rejected under 35 U.S.C. § 102 (e) as being 
anticipated by U.S. Patent 6,718,332 to Sitaraman et al. A claim is anticipated only if each and 
every element is found in a single prior art reference. See Verdegaal Bros. v. Union Oil Co. of 
California, 814 F.2d 628, 631, 2 U.S.P.Q. 2d (BNA) 1051, 1053 (Fed. Cir. 1987). See also 
DEPARTMENT OF COMMERCE, MANUAL OF PATENT EXAMINING PROCEDURE, § 2131 (orig. 8 th 
Edition) (hereinafter "M.P.E.P."). As the Assignee shows, however, the pending claims already 
patentably distinguish over Sitaraman. The patent to Sitaraman et al. fails to disclose each and 
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every element of the pending claims, so the Assignee respectfully requests that Examiner 
Abrishamkar remove the 35 U.S.C. § 102 (e) rejection. 

Claims 1-7, 10-18, and 21-30 are not anticipated. These claims recite, or incorporate, 
features not disclosed by Sitaramtm. Independent claim 1, for example, recites "validation rules 
comprising at least three hierarchically organized views, with each view utilizing an execution 
sequence of validation methods." Claim 1 additionally recites "wherein each execution sequence 
designates an order of execution for the validation methods." Independent claim 1 is reproduced 
below, and independent claims 12, 22, and 23 recite similar features. 

1. (Previously Presented) A client-server computer system for use with web-based 

applications comprising: 

a computer system running one or more web browsers capable of processing web 

forms; 

a web server capable of processing Java code and web-based forms; 

a storage mechanism coupled to said computer system, wherein said web server 
is used for validating data with information compiled from said storage mechanism; 

validation rules stored in said storage mechanism, the validation rules 
comprising at least three hierarchically organized views, with each view utilizing an 
execution sequence of validation methods; 

wherein each execution sequence designates an order of execution for the 
validation methods; and 

wherein each validation method compares validation values to the data. 

The patent to Sitaraman et al. does not anticipate claims 1-7, 10-18, and 21-30. No 
where, for example, does Sitaraman disclose "validation rules comprising at least three 
hierarchically organized views, with each view utilizing an execution sequence of validation 
methods" (emphasis added). Examiner Abrishamkar is correct — Sitaraman's "data validator" 
validates data. Yet no where does Sitaraman describe or discJose "hierarchically organized 
views" and "an execution sequence." While Sitaraman provides some explanation of this 
validation, Sitaraman is entirely silent to any description of "hierarchically organized views" of 
validation rules, "with each view utilizing an execution sequence of validation methods." The 
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passages of Sitaraman cited by Examiner Abrishamkar are reproduced below, and no where do 
these passages make any disclosure of at least these features: 

Upon the receipt of each event carrying a user record, data validator 82 validates each 
user record received. Data validator 82 validates the user record by determining whether an 
attribute definition includes an attribute name and an attribute type having the proper values, and 
whether the attribute definition contains a complete set of values. These determinations are based 
on the specific application or protocol listed in a dictionary name associated with each attribute 
definition. For example, if an attribute definition defines an attribute of a particular protocol then 
the attribute name, attribute value, and attribute type listed within the attribute definition must 
conform to the attribute dictionary of that particular protocol in order to be found valid. An 
attribute dictionary defines the attribute names, values, and types for a particular protocol, e.g., an 
attribute dictionary exists for the RADIUS protocol and its variations implemented by various 
vendors. 

For instance, if attribute name location 58 in FIG. 3 contains the string "password," and if 
the attribute dictionary listed in dictionary name location 56 defines an attribute name of 
"password", data validator 82 will deem the value held in attribute name location 58 valid because 
the value held by attribute name location 58 corresponds to one of the attributes used by the 
protocol defined by dictionary name location 56. In another example, if attribute name location 58 
holds the string "pword." and the attributes used by the protocol defined by dictionary name 
location 56 does not include an attribute name of "pword", data validator 82 will deem the value of 
attribute name location 58 invalid. 

Data validator 82 also validates the content of attribute value location 60 by determining 
whether the listed attribute value is of the proper value type for the attribute name held in attribute 
name location 58. For example, if attribute name location 58 contains the term "phone_number" 
and if the protocol listed in dictionary name location 56 defines a phone number attribute having a 
numerical value type rather than a string value type, data validator 82 will deem the content within 
attribute value location 60 invalid because it has a value type that does not match the value type 
required by the protocol listed for the attribute name. 

Data validator 82 also checks for completeness by checking whether a value exists in each 
attribute definition location that requires a value by the protocol listed in dictionary name location 
56. For example, if dictionary name location 56 contains the value "VendorA-Radius", and 
attribute name location 58 contains an IP address, data validator 82 will determine whether a value 
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exists within attribute type location 62 because the VendorA-Radtus value pertains to a protocol 
that requires an attribute type in addition to an attribute name and attribute value corresponding to 
the attribute name. 

If data validator 82 finds any of the values held by attribute name location 58 or attribute 
value location 60 invalid, or the attribute definition incomplete, data validator 82 drops the 
corresponding user record, sends an alert message to an operator, and waits for another event 
containing another user record to process. Otherwise, data validator 82 repeats the above 
validation process for each attribute definition listed in a user record. 

If data validator 82 finds all attribute definitions valid within a given user record, then the 
user record is transferred to attribute definition transcriber 84. Attribute definition transcriber 84 
converts the human readable form of the dictionary name, attribute name, and attribute type into 
descriptions that comply with the descriptions that have been standardized for, or are required by, 
a particular application or protocol used by target system 18. Thus, attribute definition transcriber 
84 converts the each attribute definition from a first description, e.g., human readable form, into a 
second description. 

U.S. Patent 6,718,332 to Sitaraman et al. (Apr. 6, 2004) at column 7, line 11 through column 8, 
line 3. 

The patent to Sitaraman et al., then, does not anticipate claims 1-7, 10-18, and 21-30. 
These passages quoted above make no mention of "hierarchically organized views" of validation 
rules, "with each view utilizing an execution sequence of validation methods" as the independent 
claims recite. Moreover, the remaining passages of Sitaraman are equally silent to such features. 
Because Sitaraman is silent to at least these features, the patent to Sitaraman et al. cannot 
anticipate the pending claims. The Assignee, then, respectfully requests that Examiner 
Abrishamkar remove the § 102 rejection of claims 1-7, 10-18, and 21-30. 

Rejection of Claims under 35 U.S.C. § 103 (a) 

Claims 9 and 20 were rejected under 35 U.S.C. § 103 (a) as being unpatentable over 
Sitaraman. Claims 8 and 19 were rejected under 35 U.S.C. § 103 (a) as being unpatentable over 
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Sitaraman in view of U.S. Patent 6,078,918 to Allen et al. If the Office wishes to establish a 
prima facie case of obviousness, three criteria must be met: 1) combining prior art requires 
"some teaching, suggestion, or motivation to do so found either in the references themselves or in 
the knowledge generally available to one of ordinary skill"; 2) there must be a reasonable 
expectation of success; and 3) all the claimed limitations must be taught or suggested by the prior 
art. DEPARTMENT OF COMMERCE, MANUAL OF PATENT EXAMINING PROCEDURE, § 2143 (orig. 
8* Edition) (hereinafter "M.P.E.P."). 

Claims 8, 9, 19, and 20 are not obvious. These claims are dependent upon their 
respective base claims and, therefore, incorporate the same distinguishing features. These 
claims, for example, incorporate "hierarchically organized views" of validation rules, "with each 
view utilizing an execution sequence of validation methods." Because Sitaraman and Allen both 
fail to teach or suggest these features, one of ordinary skill in the art would not consider these 
claims obvious over the proposed combination of Sitaraman and Allen. The Assignee thus 
respectfully requests that the § 103 rejection be removed. 

Moreover, Examiner Abrishamkar has failed to make a prima facie case. Examiner 
Abrishamkar has failed to cite "some teaching, suggestion, or motivation" to combine references. 
Examiner Abrishamkar has also failed to identify "a reasonable expectation of success." The 
Office, then, has failed their burden. The prima facie case must fail, so the Office is required to 
remove the § 103 rejection. 



If any questions arise, the Office is requested to contact the undersigned at (919) 387- 
6907 or scott ® wzpatents. com . 



Respectfully submitted. 




Scott P. Zimmerman, Reg. No. 41,390 
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